定义
本指导规范适用于存在用户界面的系统需求分析及设计，对业务部门所给予的需求，利用技术及工具进行业务规则、业务范围、业务流程等方面分析，并产出开发人员可以理解的需求分析产出。
需求分析流程
用例分析
理清业务需求是所有分析与设计的前提：
- 确定系统的「关系人」及他们的「关注点」。
- 确定系统的业务需求，即「谁」使用该系统「做什么」。
- 确定系统的功能范围，即该系统「包含什么」，不包含「什么」。
系统需要满足关系人的所有关注点，所以要确保所有这些关注点都有涉及到。最重要的关系人当然就是用户（有时还会细分为不同类型的用户），其他的还有系统数据的间接用户、领导等。
关联附件：
建立实体模型
实体模型是确定系统包含的实体以及它们之间的关联的过程：
- 理清业务概念，统一业务词汇。
- 抽象业务实体，包括事件、人/角色、地点和事物等。
- 识别实体关系：继承、聚合、关联等。
实体模型也叫 ER（Entity-Relation）模型。需要注意的是一定要理清业务的概念，统一命名和定义业务相关词汇，这是进一步沟通的基础。
关联附件：
物理模型设计(数据库设计)
根据实体模型由专门的技术人员进行数据库设计
功能结构设计
确定系统内部的功能模块及其职责：
- 确定系统的模块划分。
- 确定每个模块的职责以及模块间的关联。
功能模块对应的就是功能视图。这一步需要明确系统的功能结构，并基于功能结构进行可视化节点的划分。
系统原型设计
当上面的工作都已经做到位以后，就可以进行系统的原型设计了，设计时可以参考下面的一些设计原则
导航
-常用：将最常用的或者说最主要的功能放在主页或者最醒目的位置（不需要点击或者打开什么，直接可以开展操作）
- 其他：其他不常用的功能，有一个统一的入口，然后使用列表或者树形结构；(需要点击一个按钮后才能看见)
操作
- 不要让用户点来点去，尽量让每一次点击做尽可能多的工作
- 走一个业务流程，不要让用户从这里个窗口跳到那个窗口，从这个页面跳到那个页面，尽可能一个页面搞定
提示
- “操作成功”种类提示可以有，但是提示框会自动消失，不可以让用户确认之后提示才消失(就是不可使用alert提示成功)
- 操作失败或者警告一类提示，需要用户点击确认一下；
- 表单验证：验证失败，不要弹出alert，直接在页面给红色高亮出提示，并注明原因
- 涉及到请求服务的内容，默认显示正在加载，给予友好提示(返回数据后再显示内容)
日志
- 对于人为操作的系统业务流程原则上必须有日志记录
重点或复杂子流程设计
对于一些复杂或需要跨部门间合作的功能特性，需要对其进行跟深入的分析与设计，产出可供双方确认的文档或流程图。
工具选型
为了使各设计文档交流更加方便，工具与文档的产出关系如下
- PowerDesigner 16.5 : 《用例图》、《ER图》、《物理模型》
- MindMaster 6.5 : 《系统结构》
- Axure 8.0 : 《系统原型》
- Visio2013 : 《重点流程》